In computerized systems it is often desired to achieve authentication, secrecy and non-repudiation. Authentication provides a positive identification of an entity in the system. An entity can be a human user, a specific software component or a specific computer. Said entity is commonly defined in the art as a client or client component. Secrecy guarantees that data being stored or transmitted cannot be read by unauthorized entities. Non-repudiation guarantees that an entity cannot disown a previously issued message (also called a transaction).
These goals can be achieved using PKI (Public Key Infrastructure) technology. In PKI systems each entity is assigned a key-pair consisting of a private key and a corresponding public key. The keys are usually multi-digit numbers represented in an appropriate digital form. The keys satisfy certain mathematical properties according to the specific public-key algorithm used.
Some prior art public key algorithms are known as RSA, DH and DSA. RSA was introduced by Rivest, Shamir and Adleman and is disclosed in U.S. Pat. No. 4,405,829 which is incorporated herein by reference. DH was introduced by Diffie, Hellman and Merkle and is disclosed in U.S. Pat. No. 4,200,770 which is incorporated herein by reference. DSA (Digital Signature Algorithm) was introduced by the National Institute for Standards and Technology (NIST) and is defined at Federal Information Processing Standard (FIPS) 186-2, which is also incorporated herein by reference.
It is computationally easy to calculate the public key from a given private key, but it is extremely hard to calculate the private key given a public key.
Some public-key algorithms provide a method for calculating a digital signature of a message using an entity's private key.
A digital signature is data that is a unique binding of the message and the signer's private key. The digital signature can be verified using the original message and the signer's public key, and thus proves the authenticity of the message and provides non-repudiation.
Some public-key algorithms provide a method for encrypting a message using an entity's public key. An encrypted message can only be decrypted using that entity's corresponding private key and thus providing secrecy.
In order to verify a digital signature, authenticate a transaction, or encrypt a message, entities in a PKI based system need access to other entities' public keys. This is usually achieved by means of a public-key database (commonly referred to as the directory).
Certificates are used to bind an entity's identity to their public keys. This binding is needed in order to allow storage and distribution of public keys without the risk that public keys will be replaced by rouge elements.
A certificate is a message that contains the identity of an entity (using its name, address, department etc.), the entity's public key, validity period and a digital signature of these items. This digital signature is calculated by a CA (Certificate Authority) using the CA's private key. The CA's public key is published in the directory or otherwise accessible to the entities that use the CA services.
A CA also publishes a CRL (Certificate Revocation List) periodically. The CRL is a message signed by the CA containing references to every certificate issued by the CA which has been revoked. Revocation can occur when the security of the private key of the entity for which the certificate was issued is reported to be compromised. By checking the CRL, entities can make sure that certificates are indeed valid.
In order to verify the authenticity of certificates and CRLs, an entity needs access to the CA's public key. This is usually provided as a self-signed CA certificate, which is assumed to be locally available to all entities in the system.
In existing PKI based systems, each entity will go through an enrollment process before it can enjoy the benefits of the system. The enrollment process usually includes generating a key pair, generating and sending the CA a certificate request and receiving the entity's certificate from the CA.
In the normal day-to-day operation of PKI based systems, entities access a directory, retrieve other entities' certificates, verify them against the latest CRL, and then use the public key contained in the certificate to encrypt a message or to verify a digital signature. Entities use their private keys to sign messages and to decrypt encrypted data.
Periodically, an entity will need to re-enroll either because a new private key needs to be generated (due to the loss and revocation of the previous key), or because its certificate has expired.
As mentioned earlier, each entity must have means for generating and storing the key-pair as well as the certificate. This medium is referred to as a private-key token.
Tokens are available in existing systems in one of two forms: a software implementation or a hardware implementation. A software implementation stores the private key and certificate on a general purpose computer system in a conventional non-volatile storage medium (such as a hard disk), and performs all the calculations that use the private key using the general purpose computer system CPU.
This kind of implementation usually stores the private key encrypted using a conventional symmetric encryption algorithm (such as DES) with the key derived out of a password or pass-phrase. Knowledge of the password allows access and usage of the stored private key.
Hardware implementation store the private key and certificate on a separate dedicated platform that contains non-volatile storage and a CPU, which is used to perform all the calculations that use the private key. The most common form of hardware implementations is a smartcard (as defined by ISO 7816). A smartcard will typically authenticate the entity wishing to use the stored private key using a password.
Some prior art PKI systems suffer from various disadvantages that slowed down the assimilation of PKI technology and prevented widespread deployment of PKI technology.
Software implementations are vulnerable to password guessing attacks (also known as dictionary attacks). Since the encrypted stored private key can be copied by rouge software running on the general purpose platform, and then the user's password can be searched for, and the key decrypted.
Software implementations are vulnerable to private-key theft. Rouge software running on the general purpose platform can be designed to copy the private key as its being used by the CPU during a signature or a decryption calculation.
Software implementations usually severely limit the mobility of the user. Since most software implementations store the private key and certificate in a special file or in the system's registry, a complex export-import procedure is required in order to allow copying of the private key from one machine to the other.
Software implementations may force the user to re-enroll following a system failure (such as a hard-disk crash), which limits their utility.
Software implementations may require a complex cleansing of the system when a machine is to be reused or serviced by another person in order not to expose the previous user's private key.
Since software and hardware implementations set and use the private key protection password locally, it is usually impossible to ‘unlock’ a private key once a password is forgotten or lost.
When a private key needs to be administratively revoked (for example when employment of the key-holder is terminated), the cooperation of the key-holder is needed in order to ensure that no use of the key is made until the next release of a CRL. Such cooperation may not be forthcoming.
Hardware implementations incur a high per-seat cost.
Hardware implementations need creation of a logistical support system for replacing stolen, lost or damaged tokens as well as for the initial distribution.
Management of potentially very large number of distributed tokens is problematic especially for removable devices. This relates to system wide updates, such as token format version changes, re-issuing of CA and user certificates, etc.
Since usage of the PKI system is usually mandated by the organizational security policy and does not provide immediate functional benefit to users, active user involvement (mainly during enrollment and re-enrollment) must be minimized if the system deployment is to succeed.
When tokens are distributed across multiple platforms, it is impossible to create a centralized audit log of all the sensitive operations (such as digital signatures) performed using those tokens.
The use of a separate password for accessing the user's private key adds to the burden of passwords to be remembered and periodically changed by the user. This might lead to poor (easily guessed) choice of passwords.
Most commercial PKI systems require administrators to maintain a separate user database for certificate issuing/enrolment purposes. This duplication translates to higher costs and the possibility of loss of synchronization between the PKI user database and the organizational user database.
Roaming servers attempt to address the user mobility issue by storing a software token on a centralized server and providing a method for downloading it to the required computer being used. This solution does not address the basic security problem of software tokens caused by local use of the private key in the clear by a potentially un-trusted platform and do not allow for centralized management of the tokens.
U.S. patent application 2002/0144109 of Benantar et al. describes a system and method that involves sending a client by email and requesting information and generating a pair of keys by a client browser type application.